Apparatus and method for virtualizing a connection to a node in an industrial control and automation system

ABSTRACT

An apparatus includes first hardware configured to communicate, via a first interface, over a supervisory control network with one or more components of an industrial process control and automation system. The apparatus also includes second hardware configured to communicate, via a second interface, with a computing platform that virtualizes at least one other component of the industrial process control and automation system. The apparatus further includes a third interface configured to transport information between the first and second hardware.

CROSS-REFERENCE TO RELATED APPLICATION AND PRIORITY CLAIM

This application claims priority under 35 U.S.C. § 119(e) to U.S.Provisional Patent Application No. 62/016,938 filed on Jun. 25, 2014.This provisional patent application is hereby incorporated by referencein its entirety.

TECHNICAL FIELD

This disclosure relates generally to industrial process control andautomation systems. More specifically, this disclosure relates to anapparatus and method for virtualizing a connection to a node in anindustrial control and automation system.

BACKGROUND

Industrial process control and automation systems are routinely used toautomate large and complex industrial processes. Distributed processcontrol and automation systems are routinely arranged in different“levels.” For example, controllers in lower levels are often used toreceive measurements from sensors and generate control signals foractuators. Controllers in higher levels are often used to supporthigher-level functions, such as scheduling, planning, and optimizationoperations.

In a distributed control system, devices on certain levels are oftenconnected to associated communication networks using special hardwareinterfaces. Because of such tight couplings with the hardwareinterfaces, these devices often cannot be virtualized, which may beneeded or desired for older legacy devices or other types of devices.

SUMMARY

This disclosure provides an apparatus and method for virtualizing aconnection to a node in an industrial control and automation system.

In a first embodiment, an apparatus includes first hardware configuredto communicate, via a first interface, over a supervisory controlnetwork with one or more components of an industrial process control andautomation system. The apparatus also includes second hardwareconfigured to communicate, via a second interface, with a computingplatform that virtualizes at least one other component of the industrialprocess control and automation system. The apparatus further includes athird interface configured to transport information between the firstand second hardware.

In a second embodiment, a system includes a network interface device anda computing platform. The network interface device includes firsthardware configured to communicate, via a first interface, over asupervisory control network with one or more components of an industrialprocess control and automation system. The network interface device alsoincludes second hardware and a third interface configured to transportinformation between the first and second hardware. The computingplatform is configured to virtualize at least one other component of theindustrial process control and automation system. The second hardware isconfigured to communicate, via a second interface, with the computingplatform.

In a third embodiment, a method includes using first hardware of anetwork interface device to communicate, via a first interface, over asupervisory control network with one or more components of an industrialprocess control and automation system. The method also includes usingsecond hardware of the network interface device to communicate, via asecond interface, with a computing platform that virtualizes at leastone other component of the industrial process control and automationsystem. The method further includes transporting information between thefirst and second hardware using a third interface of the networkinterface device.

Other technical features may be readily apparent to one skilled in theart from the following figures, descriptions, and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of this disclosure, reference is nowmade to the following description, taken in conjunction with theaccompanying drawings, in which:

FIGS. 1A and 1B illustrate an example industrial process control andautomation system according to this disclosure

FIG. 2 illustrates an example network interface device according to thisdisclosure;

FIG. 3 illustrates example software architectures of components in anindustrial control and automation system according to this disclosure;

FIGS. 4 through 7 illustrate example systems using the network interfacedevice according to this disclosure; and

FIG. 8 illustrates an example method for virtualization of a connectionto a node in an industrial control and automation system according tothis disclosure.

DETAILED DESCRIPTION

FIGS. 1A through 8, discussed below, and the various embodiments used todescribe the principles of the present invention in this patent documentare by way of illustration only and should not be construed in any wayto limit the scope of the invention. Those skilled in the art willunderstand that the principles of the invention may be implemented inany type of suitably arranged device or system.

FIGS. 1A and 1B illustrate an example industrial process control andautomation system 100 according to this disclosure. As shown in FIG. 1A,the system 100 includes one or more controllers 102, which are oftensaid to reside within or form a part of a “Level 1” controller networkin a control and automation system. Each controller 102 is capable ofcontrolling one or more characteristics in an industrial process system.A process system generally represents any system or portion thereofconfigured to process one or more products or other materials in somemanner. For instance, the controllers 102 could receive measurementsfrom one or more sensors and use the measurements to control one or moreactuators.

The controllers 102 communicate via a network 103 with at least onegateway 104. The network 103 represents one or more communication pathsthat support interactions with the controllers 102 using an industrialcommunication protocol. The network 103 represents any suitableindustrial process control network.

In this example, the controllers 102 communicate with higher-leveldevices and systems via the gateway(s) 104. Here, each gateway 104facilitates communication between the network 103 and a supervisorynetwork 106, such as a local control network (LCN). Each gateway 104includes any suitable structure facilitating communication with one ormore devices via a supervisory network. The supervisory network 106represents a network facilitating communication among higher-levelprocess control and automation devices and systems.

The system 100 could also include one or more advanced controllers 108that communicate over an advanced control network 110. The advancedcontrollers 108 represent controllers that are newer, moretechnologically advanced, or more feature-rich than the controllers 102.Similarly, the control network 110 could represent a newer, moretechnologically advanced, or more feature-rich network for transportingcontrol information, such as an Internet Protocol (IP)-based network. Inparticular embodiments, the advanced controllers 108 could representC300 controllers from HONEYWELL INTERNATIONAL INC., and the controlnetwork 110 could represent a FAULT TOLERANT ETHERNET (FTE) or otherredundant IP-based network.

Various other components in the system 100 support a wide range ofprocess control and automation-related functions. For example, one ormore operator consoles 112 can be used by operators to interact with thesystem 100. At least one supervisory controller 114 and at least oneserver 116 provide higher-level control in the system 100. For instance,the supervisory controller 114 and/or server 116 could perform moreadvanced planning or scheduling operations, execute higher-level controlstrategies, or perform other functions. At least one applicationprocessing platform 118 can be used to automate various procedures inthe system 100. At least one historian 120 can be used to collect andstore data associated with operation of the system 100 over time.Various ones of these components are often said to reside within or forma part of a “Level 2” supervisory network in a control and automationsystem.

Each operator console 112 includes any suitable structure forfacilitating operator interactions, such as an EXPERION STATION TPS(EST) from HONEYWELL INTERNATIONAL INC. Each controller 114 includes anysuitable structure for providing supervisory control, such as anAPPLICATION CONTROL ENVIRONMENT-TPS (ACE-T) node from HONEYWELLINTERNATIONAL INC. Each server 116 represents any suitable computingdevice, such as an EXPERION SERVER TPS from HONEYWELL INTERNATIONAL INC.(or a redundant pair of such servers). Each application processingplatform 118 includes any suitable structure for executing automatedprocedures, such as an APPLICATION MODULE (AM) from HONEYWELLINTERNATIONAL INC. Each historian 120 includes any suitable structurefor storing data, such as a HISTORY MODULE (HM) from HONEYWELLINTERNATIONAL INC.

As described above, in a distributed control system, devices on certainlevels are often connected to associated communication networks usingspecial hardware interfaces. For example, operator consoles 112 andcontrollers 114 on “Level 2” of the system 100 are often coupled to anLCN or other supervisory network 106 using special hardware interfacesinstalled on their computer platforms. Because of this, these devicesoften cannot be virtualized. An example of this problem occurs with theattempted virtualization of HONEYWELL EXPERION TPS nodes, such as EST,ESVT, ACET, and EAPP nodes. These are WINDOWS-based nodes that areinterfaced to an LCN via special PCI hardware interfaces known asLCNP4/LCNP4e interfaces.

This disclosure describes techniques that decouple hardware/platformdependency and enable the virtualization of legacy or other devices.This is accomplished by moving the LCN or other network interface out ofa legacy or other device and installing the network interface as anindependent “network interface device.” A mechanism is also provided toestablish communications between the legacy or other device and thenetwork interface device, such as via an Ethernet network. In this way,communications over an LCN or other supervisory network 106 aresupported using the network interface device, but this functionality isdecoupled from the legacy or other control device, allowing the legacyor other control device to be virtualized.

An example of this is shown in FIG. 1B, where a computing platform 150is used in conjunction with a network interface device 152. Thecomputing platform 150 represents any suitable computing device that canbe used to virtualize at least one legacy or other device in anindustrial process control and automation system. For example, thecomputing platform 150 could include one or more processing devices 154,one or more memories 156, and one or more network interfaces 158. Eachprocessing device 154 includes any suitable processing or computingdevice, such as a microprocessor, microcontroller, digital signalprocessor, field programmable gate array (FPGA), application specificintegrated circuit (ASIC), or discrete logic devices. Each memory 156includes any suitable storage and retrieval device, such as a randomaccess memory (RAM), Flash or other read-only memory (ROM), magneticstorage device, solid-state storage device, optical storage device, orother storage and retrieval device. Each interface 158 includes anysuitable structure facilitating communication over a connection ornetwork, such as a wired interface (like an Ethernet interface) or awireless interface (like a radio frequency transceiver). In particularembodiments, the computing platform 150 could be used to virtualize anyof the “Level 2” devices shown in FIG. 1A.

The network interface device 152 facilitates communication by thecomputing platform 150 over the LCN or other supervisory network 106,but the network interface device 152 communicates with the computingplatform 150 over the advanced control network 110 (such as an Ethernetor FTE network). In some embodiments, the network interface device 152includes or supports hardware 160, interface 162, hardware 164,interface 166, and interface 168. The hardware 160 is provided with thecapability to host software performing the functionality of a “Level 2”device or other device. The interface 162 provides an interface for thehardware 160 to connect to and communicate on the LCN or othersupervisory network 106. The hardware 164 acts as a bridge interfacebetween the hardware 160 and the computing platform 150. The interface166 provides an interface for the hardware 164 to connect to andcommunicate with the computing platform 150, such as via an Ethernet orFTE network. The interface 168 establishes communications between thehardware 160 and the hardware 164. The components 160-168 can bephysically separate or operate on the same physical hardware but asdistinct logical entities. In this scheme, the computing platform'sapplications access the data from the hardware 160 via the hardware 164.

The hardware 160 includes any suitable structure supporting “Level 2” orother supervisory functionality in an industrial process control andautomation system. The hardware 164 includes any suitable structuresupporting an interface between hardware providing supervisoryfunctionality and a computing platform emulating a supervisory device.In some embodiments, each of the hardware 160, 164 is implemented usinga printed circuit board (PCB). Each interface 162, 166, 168 includes anysuitable structure for providing an interface to a network or device. Insome embodiments, the interface 162 denotes an LCN interface, theinterface 166 denotes an FTE interface, and the interface 168 denotes acommunication bus. Additional details regarding the network interfacedevice 152 are provided below.

In conventional systems, the virtualization of hardware can be preventedby the use of custom add-in cards, such as the LCNP4 card that performsthe personality function of a TPS node. Moreover, the lifetime of acomputing platform's support for internal interfaces (such as PCI busphysical connections) is typically shorter than the intended lifetime ofan industrial control or automation device. Using the network interfacedevice 152, which supports communications over a lower-level network,allows separation of the computing platform 150 from the networkinterface device 152. This approach therefore provides a solution thatenables virtualization of one or more nodes by decoupling an operatingsystem from the bus and LCN/supervisory network connections used tocommunicate with lower-level nodes while reducing obsolescence issues.This is accomplished by providing flexibility in terms of the structureof the computing platform 150 while maintaining the interface to the LCNor other supervisory network 106 via the network interface device 152.

Among other things, the approach described here can support anycombination of the following features. First, this approach can increasethe lifetime of support for an EXPERION or other software release byavoiding PC hardware obsolescence that requires OS updates. In the past,for example, moving from an obsolete server to a newer server with anewer peripheral bus often required extensive testing to ensure thenewer server was compatible with existing control technology. Theapproach described here allows the computing platform 150 to be replacedwithout requiring extensive (or any) modifications to the networkinterface device 152. Second, this approach can increase systemreliability by reducing the number of platforms through virtualization.With this approach, any number of higher-level components can bevirtualized on one or more computing platforms 150, and the networkinterface device 152 provides a remote connection external of thecomputing platform hardware. Third, this approach can decrease supportcosts for replacing PC hardware when platforms are obsolete andreplacements require software upgrades. For instance, major updates of aWINDOWS operating system may no longer require updates to orreplacements of various “Level 2” devices since those “Level 2” devicescan be virtualized. Fourth, this approach can decrease sensitivity toplatform coupling by helping to virtualize the platform, thus making theintroduction of newer technology simpler. Finally, this approach candecrease lifetime costs of a control system by extending the operationallifespan of and simplifying support for existing products.

Although FIGS. 1A and 1B illustrate one example of an industrial processcontrol and automation system 100, various changes may be made to FIGS.1A and 1B. For example, a control system could include any number ofeach component in any suitable arrangement. Components could be added,omitted, combined, or placed in any other suitable configurationaccording to particular needs. Also, particular functions have beendescribed as being performed by particular components of the system 100.This is for illustration only. In general, process control andautomation systems are highly configurable and can be configured in anysuitable manner according to particular needs. In addition, FIGS. 1A and1B illustrate an example environment in which a network interface device152 can be used. The network interface device 152 can be used in anyother suitable device or system.

FIG. 2 illustrates an example network interface device 152 according tothis disclosure. The example implementation of the network interfacedevice 152 shown here could be used to enable the virtualization ofHONEYWELL's EST, ESVT, ACET, and EAPP nodes connected to a legacy TDC3000 LCN. However, the network interface device 152 could be used tosupport any other suitable functionality.

In this specific example, the hardware 160 is implemented using a K4LCNhardware card from HONEYWELL INTERNATIONAL INC. The K4LCN hardware cardcan be mounted on a standard LCN chassis and hosts the LCN softwarepersonality of an APPLICATION MODULE (AM) or a UNIVERSAL STATION (US)with special load module components as per the network configuration.Also, in this specific example, the interface 162 is implemented usingan LCN input/output (I/O) board, which could be a standard interfaceboard through which the K4LCN card communicates over an LCN or othersupervisory network 106. Further, in this specific example, the hardware164 is implemented using a hardware card, which can be referred to as anENHANCED TPS NODE INTERFACE (ETNI). The ETNI hardware card can bemounted on the standard LCN chassis along with the K4LCN hardware card.Moreover, in this specific example, the interface 166 is implementedusing an FTE I/O board, which is an interface board through which theETNI card communicates with the computing platform 150 over an FTE orother advanced control network 110. In addition, in this specificexample, the interface 168 is implemented using a backplane module busof the LCN chassis and is the interface through which the ETNI cardcommunicates with the K4LCN card.

The overall structure shown in FIG. 2 may be referred as an ENHANCED TPSNODE (ETN). The computing platform 150 and the hardware 164 cancommunicate over FTE using any standard or proprietary protocol, such asHONEYWELL's ETN communication protocol.

In some embodiments, the network interface device 152 could supportdifferent mechanisms for accessing the computing platform 150. Forexample, the implementation of the network interface device 152 with aK4LCN hardware card could include support for different hardware slots,such as the following:

-   -   WSI2: To interface the K4LCN card with WINDOWS X-LAYER        communication services running on the computing platform 150;    -   PDG: To interface the K4LCN with the NATIVE WINDOW DISPLAY        applications running on the computing platform 150; or    -   SCSI: To enable the K4LCN card to access EMULATED DISK files        residing on the computing platform 150.        Though the ETNI can represent a single card occupying a single        physical slot on an LCN chassis, an FPGA implementation of the        ETNI card could act as three devices as per configuration needs        on the module bus of the LCN chassis, namely a WSI2 (Work        Station Interface), a PDG (Peripheral Display Generator), and a        SCSI (Smart Computer Systems Interface). These three different        hardware interfaces can be implemented on a single ETNI board.        The ETNI card can also be implemented with a mechanism to enable        or disable any of these slots, such as automatically during        start-up, which makes it a common interface that can be used for        EAPP, ESVT, EST, and ACET nodes without any hardware/firmware        changes. The slots used to support the ETNI for different types        of devices can include the following:    -   EST: PDG, SCSI and WSI2    -   EAPP, ESVT and ACET: Only WSI2        These slots can be enabled or disabled dynamically based on the        configuration from the computing platform 150.

Although FIG. 2 illustrates one example of a network interface device152, various changes may be made to FIG. 2. For example, the types ofnetworks and circuit cards shown in FIG. 2 are for illustration only.The use of particular protocols and interfaces (such as LCN, K4LCN,ETNI, and FTE interfaces) are for illustration only. Any other oradditional interfaces can be used in or with one or more networkinterface devices 152 without departing from the scope of thisdisclosure. For instance, the supervisory network 106 could beimplemented in the future as an IP/Ethernet-based network (such as anFTE-based LCN), and the network interface device 152 could support asuitable interface and hardware for that type of LCN.

FIG. 3 illustrates example software architectures of components in anindustrial control and automation system according to this disclosure.More specifically, FIG. 3 illustrates an example high-level softwarearchitecture 300 of a computing platform 150 that virtualizes one ormore legacy or other devices in a control and automation system. FIG. 3also illustrates an example high-level software architecture 350 of anetwork interface device 152.

As shown in FIG. 3, the software architecture 300 includes a kernelspace 302 and a user space 304. The kernel space 302 denotes the logicalspace within the software architecture 300 where the operating system'skernel executes for the computing platform 150. The user space 304denotes the logical space within the software architecture 300 whereother applications, such as applications 306-308, execute in thecomputing platform 150. Any suitable applications can be executed withinthe user space 304, such as a Local Control Network Processor (LCNP)status application or a NATIVE WINDOW DISPLAY application.

An emulator service 310 is also executed within the user space 304. Theemulator service 310 operates to emulate the physical interfaces thatvirtualized devices expect to be present at the computing platform 150(but that are actually implemented remotely at the network interfacedevices 152). For example, the emulator service 310 could emulate thecircuit cards that are expected in different virtualized slots. As aparticular example, slot 2 could be a WSI card, Slot 3 could be a SCSIcard, and Slot 4 could be an Enhanced Peripheral Display Generator(EPDG) card.

The emulator service 310 also supports the use of one or more sockets312, which are used to communicate via an FTE module 314 in the kernelspace 302. The FTE module 314 supports various functions allowingredundant communications over the advanced control network 110, such asheartbeat signaling and processing. Although not shown, the kernel space302 could support various other features, such as emulated TOTALDISTRIBUTED CONTROL (TDC) memory, slot registers, and LCNP4e registers.

The software architecture 350 includes a TDC personality 352 in thehardware 160. The TDC personality 352 denotes one or more softwareroutines that provide the personality function of a TPS node. From theperspective of other devices connected to the LCN or other supervisorynetwork 106, the TDC personality 352 causes the network interfacedevices 152 to appear as a standard supervisory device, even though theactual functionality of the supervisory device is virtualized andexecuted by the computing platform 150. The TDC personality 352communicates with slot registers 354 in the hardware 164, which could beimplemented using an FPGA or other suitable structure. In particularembodiments, the slot registers 354 could include three standard slotregister sets that are expected in any standard TDC device.

Firmware 356 executed by the hardware 164 includes slot emulation tasks358 and an FTE module 360. Among other things, the slot emulation tasks358 can emulate the operations needed to interact with the TDCpersonality 352. For example, the WSI subsystem of a conventional TDCpersonality 352 sets up WSI slot registers with mailboxes and semaphoresand manages a linked list of TDC memory data buffers. The WSI subsystemalso watches the mailboxes for data buffers going to the TDC personality352 and places data buffers into the mailboxes coming from the TDCpersonality 352. The slot emulation tasks 358 could emulate thesefunctions to support data transfers to and from the computing platform150 via the network 110. The FTE module 360 supports various functionsallowing redundant communications over the advanced control network 110,such as heartbeat signaling and processing.

Although FIG. 3 illustrates examples of software architectures 300, 350of components in an industrial control and automation system, variouschanges may be made to FIG. 3. For example, the particular mechanismsshown here for supporting interactions between the computing platform150 and the network interface device 152 are examples only. Also, thetypes of networks and circuit cards shown in FIG. 3 are for illustrationonly.

FIGS. 4 through 7 illustrate example systems using network interfacedevices 152 according to this disclosure. As shown in FIG. 4, thenetwork interface device 152 is coupled to an LCN or other supervisorynetwork 106. The network interface device 152 is also coupled to an FTEor other advanced control network 110, namely a network switch 402 thatsupports communications between the network interface device 152 and thecomputer platform 150. The network switch 402 supports data transportbetween the network interface device 152 and the computer platform 150in accordance with an advanced control network protocol.

As shown in FIG. 5, the network interface device 152 is implementedusing a chassis 502, which includes various dual node card fileassemblies (CFAs) 504. The CFAs 504 can receive various circuit boards,including the hardware cards implementing the hardware 160, theinterface 162, the hardware 164, and the interface 166. A backplane ofthe chassis 502 could be used as the interface 168.

The chassis 502 is coupled to two network switches 506 a-506 b, whichare coupled to the computing platform 150. In this example, thecomputing platform 150 supports a virtualization environment in whichvarious virtual machines (VMs) 508 can be executed. The virtual machines508 can virtualize a variety of industrial control and automationapplications. In this example, the virtual machines 508 virtualizeHONEYWELL EXPERION PKS server, ACE/APP, PROCESS HISTORY DATABASE (PHD),and domain controller applications. A management application 510supports various management functions for controlling the virtualizationenvironment. In this particular implementation, the virtualizationenvironment is supported using VMWARE ESXI SERVER software, and themanagement application 510 denotes the VMWARE VSPHERE MANAGEMENTapplication. Note, however, that any suitable virtualization softwareand management application could be used. Also note that the computingplatform 150 could be implemented using a “bare metal” approach.

As shown in FIG. 6, the network interface device 152 is coupled to aredundant pair of “Level 2” network switches 602 a-602 b, which supportan FTE network as the advanced control network 110. The switches 602a-602 b are coupled to “Level 2” devices such as EXPERION TPS nodes 604.The switches 602 a-602 b are also coupled to a redundant pair of “Level1” network switches 606 a-606 b and a redundant pair of firewalls 608a-608 b, such as HONEYWELL CONTROL FIREWALL (CF9) devices. Variousdevices 610 are coupled to the “Level 1” network switches 606 a-606 band the firewalls 608 a-608 b, and devices 610-612 are coupled to theLCN or other supervisory network 106.

As shown in FIG. 7, one or more network interface devices 152 aremounted to an operator console 702 and coupled to a switch 704 over anFTE or other advanced control network 110. The computing platform 150 isimplemented here as a computing tower, although any other suitable formcould be used. A thin client 706 denotes a platform that can be used asa way to remote the keyboard, mouse, custom keyboard, and monitormounted in the console furniture of the operator console 702.

Although FIGS. 4 through 7 illustrate examples of systems using networkinterface devices 152, various changes may be made to FIGS. 4 through 7.For example, these figures are meant to illustrate general examples ofthe types of ways in which the network interface device 152 could beimplemented and used. However, the network interface device 152 could beimplemented and used in any other suitable manner.

FIG. 8 illustrates an example method 800 for virtualization of aconnection to a node in an industrial control and automation systemaccording to this disclosure. As shown in FIG. 8, a network interfacedevice is coupled to a “Level 2” network and a supervisory network atstep 802. This could include, for example, coupling the networkinterface device 152 to an FTE or other advanced control network 110 andan LCN or other supervisory network 106.

A computing platform is coupled to the “Level 2” network at step 804.This could include, for example, coupling a computing platform 150 tothe FTE or other advanced control network 110. One or more virtualmachines are executed on the computing platform at step 806. This couldinclude, for example, executing virtual machines that virtualize variousindustrial process control and automation Level 2 devices on thecomputing platform 150.

The network interface device bridges the virtualized componentsexecuting on the computing platform and lower-level devices accessiblevia the LCN or other supervisory network. For example, first data isreceived from one or more virtual machines at the network interfacedevice at step 808 and provided over the supervisory network by thenetwork interface device at step 810. This could include, for example,the network interface device 152 receiving data from the computingplatform 150 over the FTE or other advanced control network 110 (via thehardware 164 and interface 166) and providing the first data over theLCN or other supervisory network 106 (via the hardware 160 and interface162). Similarly, second data is received from the supervisory network atthe network interface device at step 812 and provided to one or morevirtual machines over the Level 2 network at step 814. This couldinclude, for example, the network interface device 152 receiving datafrom lower-level devices over the LCN or other supervisory network 106(via the hardware 160 and interface 162) and providing the second datato the computing platform 150 over the FTE or other advanced controlnetwork 110 (via the hardware 164 and interface 166). The interface 168supports data transport between the hardware 160 and the hardware 164.

In this way, the actual interface to an LCN or other supervisory network106 is supported by the network interface device 152, which is separatedfrom the computing platform 150 that executes virtualized controlcomponents. The virtualized control components can therefore be added,modified, or removed more easily since the control components are nottied to special hardware interfaces.

Although FIG. 8 illustrates one example of a method 800 forvirtualization of a connection to a node in an industrial control andautomation system, various changes may be made to FIG. 8. For example,while shown as a series of steps, various steps in FIG. 8 could overlap,occur in parallel, occur in a different order, or occur multiple times.

In some embodiments, various functions described above are implementedor supported by a computer program that is formed from computer readableprogram code and that is embodied in a computer readable medium. Thephrase “computer readable program code” includes any type of computercode, including source code, object code, and executable code. Thephrase “computer readable medium” includes any type of medium capable ofbeing accessed by a computer, such as read only memory (ROM), randomaccess memory (RAM), a hard disk drive, a compact disc (CD), a digitalvideo disc (DVD), or any other type of memory. A “non-transitory”computer readable medium excludes wired, wireless, optical, or othercommunication links that transport transitory electrical or othersignals. A non-transitory computer readable medium includes media wheredata can be permanently stored and media where data can be stored andlater overwritten, such as a rewritable optical disc or an erasablememory device.

It may be advantageous to set forth definitions of certain words andphrases used throughout this patent document. The terms “application”and “program” refer to one or more computer programs, softwarecomponents, sets of instructions, procedures, functions, objects,classes, instances, related data, or a portion thereof adapted forimplementation in a suitable computer code (including source code,object code, or executable code). The term “communicate,” as well asderivatives thereof, encompasses both direct and indirect communication.The terms “include” and “comprise,” as well as derivatives thereof, meaninclusion without limitation. The term “or” is inclusive, meaningand/or. The phrase “associated with,” as well as derivatives thereof,may mean to include, be included within, interconnect with, contain, becontained within, connect to or with, couple to or with, be communicablewith, cooperate with, interleave, juxtapose, be proximate to, be boundto or with, have, have a property of, have a relationship to or with, orthe like. The phrase “at least one of,” when used with a list of items,means that different combinations of one or more of the listed items maybe used, and only one item in the list may be needed. For example, “atleast one of: A, B, and C” includes any of the following combinations:A, B, C, A and B, A and C, B and C, and A and B and C.

While this disclosure has described certain embodiments and generallyassociated methods, alterations and permutations of these embodimentsand methods will be apparent to those skilled in the art. Accordingly,the above description of example embodiments does not define orconstrain this disclosure. Other changes, substitutions, and alterationsare also possible without departing from the spirit and scope of thisdisclosure, as defined by the following claims.

What is claimed is:
 1. An apparatus comprising: at least one firsthardware card configured to communicate, via a first hardware interface,over a local control network (LCN) with one or more components of anindustrial process control and automation system; wherein the at leastone first hardware card comprises an emulated personality of asupervisory device that would communicate over the LCN; at least onesecond hardware card configured to communicate, via a second hardwareinterface, over a redundant Ethernet network with a computing platformthat virtualizes at least one other component of the industrial processcontrol and automation system wherein the at least one second hardwarecard comprises slot registers configured to store data being transferredto and from the emulated personality; and a third interface configuredto transport information between the at least one first hardware cardand the at least one second hardware card.
 2. The apparatus of claim 1,wherein the apparatus is configured to provide a remote connection intothe LCN for the at least one other component virtualized by thecomputing platform.
 3. The apparatus of claim 1, wherein the at leastone second hardware card is configured to perform one or more slotemulation tasks to support data transfer between the slot registers andthe computing platform.
 4. The apparatus of claim 1, wherein the thirdinterface comprises a backplane of an LCN chassis configured to receivethe at least one first hardware card and the at least one secondhardware card.
 5. The apparatus of claim 1, wherein: the at least onesecond hardware card is configured to occupy a single slot of a chassis;and the at least one second hardware card is configured to supportmultiple hardware interfaces and is configured to enable or disable eachof the multiple hardware interfaces.
 6. A method comprising: using atleast one first hardware card of a network interface device tocommunicate, via a first hardware interface, over a local controlnetwork (LCN) with one or more components of an industrial processcontrol and automation system; emulating a personality of a supervisorydevice that would communicate over the LCN using the at least one firsthardware card; using at least one second hardware card of the networkinterface device to communicate, via a second hardware interface, over aredundant Ethernet network with a computing platform that virtualizes atleast one other component of the industrial process control andautomation system; transporting information between the at least onefirst hardware card and the at least one second hardware card using athird interface of the network interface device; and storing data beingtransferred to and from the emulated personality using slot registers ofthe at least one second hardware card.
 7. The method of claim 6, whereinthe network interface device provides a remote connection into the LCNfor the at least one other component virtualized by the computingplatform.
 8. The method of claim 6, further comprising: performing oneor more slot emulation tasks to support data transfer between the slotregisters and the computing platform using the at least one secondhardware card.
 9. The method of claim 6, wherein the third interfacecomprises a backplane of an LCN chassis configured to receive the atleast one first hardware card and the at least one second hardware card.10. The method of claim 6, wherein: the at least one second hardwarecard occupies a single slot of a chassis; the at least one secondhardware card is configured to support multiple hardware interfaces; andthe method further comprises enabling or disabling each of the multiplehardware interfaces.
 11. The apparatus of claim 1, wherein the firsthardware interface comprises an LCN input/output (I/O) board.